Lambda the Ultimate

Modeling Languages: Syntax, Semantics and all that Stuff (or, What's the Semantics of "Semantics"?)
by David Harel, Bernhard Rumpe

Motivated by the confusion surrounding the proper definition of complex modeling languages, especially the UML, we discuss the distinction between syntax and true semantics, and the nature and purpose of each.

This paper is rather light on greek letters (and category stuff is absent as well). Instead, it aims to introduce the notions of syntax, semantics, and formal definition of languages in plain prose.
If you never understood why bother with formal definitions - consider reading this!

You might want to read a longer version (Modeling Languages: Syntax, Semantics and All That Stuff Part I: The Basic Stuff). Unfortunately, I was unable to find parts II and III (The Advanced Stuff and The Really Hard Stuff) online.

Tim Harris, Simon Peyton-Jones. Transactional memory with data invariants. March 2006. TRANSACT '06, to appear.

This paper introduces a mechanism for asserting invariants that are maintained by a program that uses atomic memory transactions. The idea is simple: a programmer writes check E where E is an expression that should be preserved by every atomic update for the remainder of the program’s execution. We have extended STM Haskell to dynamically evaluate check statements atomically with the user’s updates: the result is that we can identify precisely which update is the first one to break an invariant.

The STM approach is sometimes described as being "like A and I" from ACID database transactions; that is, atomic blocks provide
atomicity and isolation, but do not deal explicitly with consistency or durability. This paper attempts to include “C” as well, by showing how to define dynamically-checked data invariants that must
hold when the system is in a consistent state.

While the basic idea is straightforward, the discussion of the design decisions in section 3.5-3.7 is an interesting exploration of the design space.

The implementation technique and operational semantics are the main contributions.

Previous draft discussed here.

Just saw this announcement on Google groups / comp.lang.python.

EasyExtend is a constructive approach to extend the Python language using pure Python. EasyExtend is developed as a Python framework depending only on tools provided by the CPython interpreter suite ( compiler ) and standard library as well as some pieces of code borrowed from the PyPy project. Opposite to toolkits for writing extension modules in C ( or RPython in future ) the EasyExtend framework is dedicated to extend the language itself by adding new grammar rules and transformation of parse trees. Acting directly on the nodes of syntax trees makes EasyExtend safe and extensible. Moreover the parser and the transformations are considerably fast. While EasyExtend can obviously be used to define "little languages" embedded in Python it can also be used to create Python oriented tools like a code coverage tool based on code generation. For both use-cases examples will be provided.

You'll want to probably want to check out the examples.

It's been quite a while since I visited codegeneration.org, and it seems like the site grew considerably, so you might want to check it out again too.

Code generation is an important programming technique (not to be confused with the code generation phase of compilers), which I am sure everyone here is familiar with. It seems to me that the percentage of programmers who know about code generation is relatively small. Am I right in this assumption? I am not asking about people actually using the technique, mind you, just about knowing that it exists and what it means, and don't think the basic idea is "strange" or involves dark magic.

I wonder where, if anywhere, should programmers (and CS students) learn about it. And no, the answer well, on LtU of course isn't a good option!

Here's a very simple implementation of Kanren that gives the barest minimum to get the taste of logic programming in very simple Scheme.

I am told that the code was written in about three hours at the meeting of a Functional Programming Group (Toukyou/Shibuya, Apr 29, 2006), as a quick illustration of logic programming.

The code is very easy to read, and the comments are instructive and helpful.

Enjoy!

Erlang/OTP R11B has now been released with support for transparently scheduling Erlang processes across multiple CPUs.

Congratulations to the OTP and HiPE teams and to Tony Rogvall for making this a reality!

The Automath Archive was created by the Brouwer Institute in Nijmegen and the Formal Methods section of Eindhoven University of Technology. Started by prof. H. Barendregt, in cooperation with Rob Nederpelt, this archive project was launched to digitize valuable historical articles and other documentation concerning the Automath project.

Initiated by prof. N.G. de Bruijn, the project Automath (1967 until the early 80's) aimed at designing a language for expressing complete mathematical theories in such a way that a computer can verify the correctness. This project can be seen as the predecessor of type theoretical proof assistants such as the well known Nuprl and Coq.
(Introduction copied from the website, hope that is allowed).

Ehud, I hope this satisfies your wish for historical CS subjects.

There are a variety of reasons why we haven’t implemented continuations in the JVM. High on the list: continuations are costly to implement, and they might reek havoc with Java SE security model. These arguments are pragmatic and a tad unsatisfying. If a feature is really important, shouldn’t we just bite the bullet?

Many here will not like the answer.

This issue was discussed here mnay time, of course, but I think it is of interest to know what the people at Sun are thinking...

Tim Bray's response is also worth checking out, if only for the sake of this sound bite: The worst AJAX apps are like bad Nineties VB.

Some of our departments receive less attention than others. This has got to stop!

In the spirit of affirmative action, here are two departments that deserve more attention (and more new items) than they currently get:

The Logic/Declarative dept. dedicated to Prolog and other logic programming languages, as well as to other forms of declarative programming (e.g., DSLs, constraints solving etc.). It also deals with all kinds of theory regarding these issues and implementation strategies.

The second department I want to highlight is the history dept. dedicated to items about the history of programming languages, and sometimes even to items about the history of programming and CS in general.

If you are a contributing editor, consider helping these departments by posting new items to them. If you are LtU regular with interest in these fields, how about signing up as a contributing editor and helping out?

Google has released a new web toolkit. The possible significant item for LtU is the Java-to-Javascript compiler that is one of the central components of the toolkit. I am unconvinced of the value of coding in java rather than in javascript. However, the marketing folks have been thinking along the same lines as some of the threads here on LtU with respect to static type checking, code completion, etc. Maybe some of the static fans could comment on this?

cheers,
Jess